1. Technical Field
The present invention relates generally to an improved data processing system and in particular to a method and apparatus for processing data. Still more particularly, the present invention relates to a method, apparatus, and computer instructions for supporting container managed persistent entity bean for a Java programming system.
2. Description of Related Art
Java is an object oriented programming language and environment focusing on defining data as objects and the methods that may be applied to those objects. Java supports only a single inheritance, meaning that each class can inherit from only one other class at any given time. Java also allows for the creation of totally abstract classes known as interfaces, which allow the defining of methods that may be shared with several classes without regard for how other classes are handling the methods. Java provides a mechanism to distribute software and extends the capabilities of a Web browser because programmers can write an applet once and the applet can be run on any Java enabled machine on the Web. The Java virtual machine (JVM) is a virtual computer component that resides only in memory. The JVM allows Java programs to be executed on different platforms as opposed to only the one platform for which the code was compiled. Java programs are compiled for the JVM. In this manner Java is able to support applications for many types of data processing systems, which may contain a variety of central processing units and operating systems architectures. To enable a Java application to execute on different types of data processing systems, a compiler typically generates an architecture-neutral file format—the compiled code is executable on many processors, given the presence of the Java run time system. The Java compiler generates bytecode instructions that are non-specific to particular computer architectures. A bytecode is a machine independent code generated by the Java compiler and executed by a Java interpreter. A Java interpreter is a module in the JVM that alternatively decodes and executes a bytecode or bytecodes. These bytecode instructions are designed to be easy to interpret on any machine and easily translated on the fly into native machine code.
In Java, independent Java program modules that are called for and executed are referred to as JavaBeans. JavaBeans have been primarily used for developing user interface on the client side. A server side counterpart of JavaBeans is present. This counterpart is referred to as Enterprise JavaBeans (EJBs). An EJB is a software component in Java 2, Enterprise Edition (J2EE) Platform. This platform provides a pure Java environment for developing and running distributed applications. EJBs are written as software modules that contain the business logic of the application. These EJBs reside in and are executed in a runtime environment called an “EJB container”, which provides common interfaces and services to the EJB. These services include security and transaction support.
Container-managed persistent (CMP) entity EJBs are in essence wrappers for persistent data with additional support for transaction control and security. The persistent data typically takes the form of relational databases. The EJB specification, version 2.0 specification, defines a high-level interface for various types of web-based application services. One of the most complex of these types of services is a container-managed persistent (CMP) entity bean. A CMP entity bean represents a unit of data held in a persistent data store, but which the end user may treat as a Java object. In these examples, the end user is typically an applications programmer. An applications server provider provides a mechanism in the form of code to implement the EJB specification for CMP entity beans and forms a bridge between the interfaces seen by the application programmer and various persistent data stores.
The EJB specification for CMP entity beans leaves an extreme degree of latitude in how the mechanism for this function actually is implemented. At the same time, there are distinct advantages in a mechanism that can be flexible in dealing with the various ways CMP beans can be used and is efficient both in speed and use of memory and other system resources. Some of the ways in which CMP beans may be used include, for example, allowing the applications programmer to be free to define any number of CMP beans of different types, each type representing some aspect of an object model. For example, bank beans, customer beans, bank account beans, and account transaction beans are CMP beans that may be defined. Each CMP bean type has aspects that are specific to that bean type and aspects that are common among the bean types. The particular data store and table of data within the data store may vary from bean type to bean type. The general mechanism, however, for communicating with the data store and the operations performed on the bean are common. These operations include, for example, create, read, update, and delete a CMP bean. Another way in which a CMP bean may be used is to have a CMP bean inherit from another. Further, CMP beans may have associations with one another. For example, a bank CMP bean may have many customer CMP beans. Further, it is advantageous to allow a change to a different data store with a minimal impact on the applications programmer and their work in defining bean types. Further, it is also advantageous to allow changes to the mechanism with minimal impact on the applications programmer and their work defining the bean types.
The fact that each CMP bean type has aspects specific to it means that some amount of generated code is likely to be present as part of a mechanism for CMP beans. These different aspects that may be specific to a CMP bean include, for example, the name of the CMP bean and the name and type of attributes for the CMP bean. A mechanism may be designed with minimal generated information for a bean and the balance being commonly shared runtime code. An example of such a bean is a CMP bean that only contains a group of string constants. Alternatively, a mechanism also may be designed with one hundred percent generated code for each CMP bean with no shared runtime code. Between these two extremes are a nearly infinite number of possible design variations. Each variation may be better or worse than others in the key measures of flexibility and efficiency. Currently, a mechanism for achieving an optimum between flexibility and efficiency is unavailable. Therefore, it would be advantageous to have an improved method, apparatus, and computer instructions for a CMP entity bean support architecture that provides a better balance between generated and runtime code in order to optimize performance.